home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19990725-20000114 / 000093_news@columbia.edu _Fri Sep 10 18:51:18 1999.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA20091
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 10 Sep 1999 18:51:17 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA24837
  7.     for kermit.misc@watsun.cc.columbia.edu; Fri, 10 Sep 1999 18:39:18 -0400 (EDT)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Subject: Re: TVI955 terminal emulation client for Unix (Linux)
  11. Date: 10 Sep 1999 22:39:17 GMT
  12. Organization: Columbia University
  13. Message-ID: <7rc1al$o82$1@newsmaster.cc.columbia.edu>
  14. To: kermit.misc@columbia.edu
  15.  
  16. In article <37D97564.CD7DB3F6@GD-CS.Com>,
  17. Scott G. Hall <Scott.Hall@GD-CS.Com> wrote:
  18. : davidrice@my-deja.com wrote:
  19. :
  20. Looks like Scott & I posted detailed replies at the same time...
  21.  
  22. : What you need is some software that will translate between the TVI955
  23. : personality for the second host, and the terminal type that you are using
  24. : on your UNIX host.  There used to be posted a few years ago the UNIX
  25. : program "pcomm", which was an implementation of Procomm for UNIX.  It
  26. : would allow any of a number of different terminal emulations, like its
  27. : PC cousin, and was written using termlib and curses so that it didn't
  28. : care what your local terminal was.
  29. :
  30. This is a possibility too but not a good one.  Since pcomm is a regular
  31. UNIX application, it can't get at the keyboard and screen any more than
  32. telnet, cu, or kermit can.  Being driven by curses doesn't solve all the
  33. problems.  First of all, the application still can't see the keys --
  34. only whatever escape sequences the keys might generate.  But that's not
  35. good enough for key mapping.
  36.  
  37. Second, curses might help in displaying the final result on the user's
  38. terminal screen, but how is the incoming stream parsed and converted into
  39. actions?  I don't think curses does that, so detailed and specific
  40. emulations STILL have to be written into the application.  This is pretty
  41. complicated stuff, and probably accounts for why we don't hear much about
  42. pcomm any more.
  43.  
  44. Third, real terminals like the VT320, TVI955, etc, strain the curses model
  45. beyond its design.  Ambitious applications written for these terminals
  46. (that use, say, protected fields, character-set switching, function-key
  47. loading, numerous report/request sequences, etc) won't be served adequately 
  48. a curses-based translator.
  49.  
  50. More adequate products (if any exist) are going to be commercial and
  51. expensive, since no terminal emulator for UNIX is going to get the kind of
  52. market share that allows low prices, and they're just not easy enough to
  53. write to be cranked out by volunteers -- and certainly not maintained by
  54. them over the long term.
  55.  
  56. It would, indeed, be possible to write an xterm that supported a wide range
  57. of terminal types, but who's going to do it?  Believe me, it is a LOT of
  58. work.
  59.  
  60. - Frank